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Remarks 

This appUcation was filed on 05 October 2001 with 58 claims. In the first 
examination of the appUcation dated 17 December 2003, the Examiner, objected to 
the Drawings, the Specification, and claim 10 because of a typographical error. The 
Examiner further rejected claims 1-58 under 35 U.S.C. § 103(a) over U.S. Patent No. 
6,088,694 entitled CONTINUOUS AvAiLABiLTrY and Efficient Backup for Externally 
Referenced OBJECTSto Bums et al. (Bums '694) in view of U.S. Patent No. 6,581,075 
entitied System and Method for Database Synchronization to Guturu et al. (Guturu 
'075). AppUcant responded on 17 March 2004 and amended the abstract, claims 1, 4, 
10, 20, 23, 24, 38, 39, 42, 43, 45, 56, 57, and 58; cancelling claims 12, 13, 31, 32, 49, 
and 50. AppUcant requested to be allowed to submit corrections to the drawings when 
Attorney for AppUcant receives copies of the drawings that were submitted and 
reviewed by the Examiner and the Official Draftsman. 

The Examiner responded with a final rejection of claims under 35 U.S.C. 
§ 103(a) under Bums '694 and Guturu '075, as weU as rejecting claims 1, 20, 39, 57 
and 58 under 35 U.S.C. §1 12, first paragraph. In response, AppUcant submit aii 
Amendment After Final Rejection under 37 CFR 1 . 1 16 putting the claims in condition 
for aUowance and/or better condition for appeal. In separate correspondence enclosed 
AppUcant submits a Proposed Amendment to the Drawing. Applicant requests the 
Examiner to enter the amendments because they do not raise new issues, nor do they 
require anew search; the amendments incorporate Umitations of preexisting and 
aU-eady searched dependent claims into the independent claims. Claims 1-11, 14-18, 
20-30, 33-37, 39-48, 51-55, 57, and 58 are pending. 

The R ejection of claims 1. 20. 39. 57 and 58 under 35 U.S.C. gl 12. first f 

The Examiner rejected claims 1, 20, 39, 57 and 58 asserting that they fail to 
comply with written description requirement. The Examiner asserts that the 
specification, as originally filed, fails to provide support for "said object capable of 
being edited independently of said related metadata." AppUcant traverses this 
rejection. 
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Applicant maintains that a "loose transaction model" Is one where the file can 
be edited independently of the metadata. It is well known that AppUcant is allowed to 
be her/his own lexicographer. In the originally filed specification on pages 1, line 26 
through page 2, line 11 , it is stated that: 

If file and meta-data updates are tightly coupled (i.e. both updates 
happen withm a single unified transaction), a transaction coordinator 
typically ensures .... On the other hand, in systems where a loose 
transaction model is provided, and direct content edits are allowed 
consistency between file-data and meta-data may not be guaranteed at 
all tunes. A need therefore clearly exists for an improved technique for 
providmg a consistent view of file data and meta-data in the presence of 
a loose-transaction model. 

Thus, if a "tightly couple transaction is one in which updates to the fUe and meta-data 
happen within a single unified transaction," it follows that a "loose transaction model" 
is one where direct content edits to the file are allowed separately fi-om direct content 
edits to the meta-data; otherwise, why would guaranteeing consistency between file- 
data and meta-data be a concern? 

Further support for inclusion of "maintaining (or ensuring) meta-data and 
object-data consistency in a loose transaction model of object and meta-data 
updates" is given in the originally filed specification on page 8, line 3 1 through page 9, 
line 1. Additionally, the Examiner is directed to the originally filed specification at 
page 1 1, lines 21-26 which states, "[t]he file is updated using normal fUe system 
appUcation program interf-aces. The file can be updated via SQL Mediated Object 
Manipulation where a handle is obtained from the mediator, that is preferably a 
filename with an encrypted access token string embedded as part of the filename, and 
is supplied as the filename to the filesystem API. The file may be updated several 
times before the file's meta-data is updated in the database." (Emphasis 
added; abbreviations and reference numerals omitted). And again, on page 15, line 
18-20, "[tjhis covers the case where an updater has modified and then closed the file 
after releasing any file locks, but has not updated the corresponding meta-data." On 
page 28, lines 11-26, "[ajs the foregoing embodiments of the invention illustrate, a 
loose transaction model for updates to a file and its corresponding meta-data through 
a mediator is useful for directly performing in-place edits of content data residing 
on stores external to the indexed meta-data store (the latter could be a DMBS). 
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This is subject to the requirement of ensuring consistency between the file content 
and the associated meta-data fi-om a reader's perspective." (Emphasis added) 

Thus. AppUcant requests the Examiner to remove the rejection of claims 1 20 
39. 57 and 58 under 35 U.S.C. §112. first paragraph because the specification does ' 
provide for editing file content separately fi-om editing the metadata relevant to that 
file. Besides. AppUcant has removed the objectionable language "loose transaction 
model" fi-om the rejected claims, reserving the right reinstate the language. 

The Rejection of claims 1-1 1 14-30. .^'^-4« si- SS under tt q n ^^n',^^^ 

The Examiner rejected claims 1-11. 14-30. 33-48 and 51-58 under 35 U.S.C 
§103(a) over Bums '694 in view Guturu '075. In response, AppUcant amends 
independent claims 1, 20, and 39 to distinctly point out and particularly claim that 
the "object can be edited independently of the related metadata." 

In amending the claims. AppUcant does not add new matter. Support for the 
updating said extemaUy stored object while said object is accessed without 
modifying said metadata in said database in the originaUy-filed appUcation is set 
forth as stated above in the remarks directed to the rejection under 35 U.S.C. §112, 
first paragraph and again on page 9. Une 1 1 which states that "the file can be edited 
independently of the metadata." 

The Examiner alleges that Bums '694 discloses the elements of the claimed 
invention, i.e., "a method of maintaining consistency of content of an object and 
metadata related." "storing said related meta-data and a reference to said object in a 
table." "the object being stored externally to said database." "said reference used to 
obtain a handle for directly accessing or manipulating said external object", and 
"obtaining a version number." The Examiner, however, admits that Bums does not 
expUcitly disclose the steps of comparing the embedded version number with a 
version number of a latest committed version of an extemally stored object to 
determine if the handle refers to a current version of the extemally stored object. 

RespectfiiUy, AppUcant maintains that Bums '694 does not teach or suggest 
the amended claim limitation that the "extemally stored object can be edited without 
modifying the metadata in the database." Recall that this was the problem solved by 
the AppUcant and one not addressed by either Bums '694 nor Gutum '075. Bums 
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'694 at column 11, lines 30-44 explains that in carrying out the file append 
operations, fields in the file metadata are set, the file is linked and then is allowed to 
be opened and then appended. "In the DataLinks system, the DLFF module permits 
the append operations to take place by setting the appropriate field values in the 
metadata [i.e., by editing the metadata]." (column 11, lines 56-59) Then the file and 
the metadata are updated in a transactional manner meaning the update to both are 
either performed completely or the update fails, (column 12, lines 4-5). Similarly, in 
the file update operations, fields in the file metadata are set [i.e., the metadata are 
edited] (column 12, lines 43-44), then the file is opened and update operations are 
performed by setting the appropriate field values in the metadata." (column 12, lines 
48-50). Bums '694, moreover, provides for "transaction atomicitsr" (column 10, lines 
65-66) when modifying the object, i.e., the appends and updates of both the 
file /object and the metadata are checked-in and conducted in a "transactional 
manner" (Bums '694 at column 12, lines 3-8 and column 13, lines 8-13) by updating 
a column in the database, (column 13, lines 5^15). 

In fact. Bums '694 is described by Applicant in the originally-filed specification 
on page 1, lines 29-32 wherein the "file and meta-data updates are tightly coupled (i.e. 
both updates happen within a single unified transaction), a transaction coordinator 
typically ensures a consistent view by locking out readers of meta-data as well as 
file data until the transaction is committed. Intermediate /uncommitted updates to 
either are not visible." See Bums '694 at column 9, lines 8-18 which states that the 
application user first issues an SQL Insert, SQL Delete, OR SQL Update call in the 
database [thereby modifying the metadata in the database] and then links the file 
with certain constraints, which include, for example, making a database system the 
owner of the named file and marking the file as a read-only file. This linkage is 
provided in a transactional manner. The rationale for changing the owner of the file to 
the database system from a file system user is to prevent the file from being renamed 
or deleted by file system users, which guarantees the integrity of any reference made 
in the database system to the file. Marking the file as read only guarantees the 
integrity of indexes that may be created on the file and stored in the database system 
for search." This is quite opposite to the claimed invention in which the metadata and 
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the file may be accessed without modifying the metadata and in which access to the 
metadata is permitted while the file/object is updated! 

As discussed in the earlier response, a "transactional manner" to preserve data 
integrity , as in Bums '694. has a clear definition in the art of database management 
with the following characteristics: a "transactional manner" is atomic meaning that 
either aU or none of the operations are completed; is consistent meaning that all 
transactions must leave the database in consistent state; is isolated meaning that the 
transactions can't interfere with each other's work and incomplete work isn't visible to 
other transactions; and is durable meaning that successful transactions must persist 
through crashes of the object/file. Quite simply, because of this "transactional 
manner". Bums '694 cannot suggest or teach that the object/file can be modified 
without modifying the metadata. 

The Examiner then proposes that the version number, timestamp. operational 
priority, and node priority parameters as taught by Gutum '075 provide sufficient 
teaching and motivation to modify Bums '694. AppUcant respectfully continue 
to traverse because neither Gutum '075 nor Bums '694 solve the stated problem of 
maintaining consistency between file content and the associated metadata, while 
permitting multiple updates to the file content. Gutum '075 solves the problem of 
synchronizing identical and redundant databases. Just as Bums '694 does not have 
the claimed elements of the amended independent claims, Gutum '075 also does not 
"update the extemally stored object/file without modifying the metadata in the 
database." Gutum '075 assumes a "tightly coupled" or a "transactional manner" in 
that the metadata related to the object being updated is never separated from the 
object. Both Bums '694 and Gutum "075 update the object and the metadata at once 
and do not suggest otherwise. Respectfiilly, comparing version numbers, timestamps 
and priorities does not allow updating the file/object without modification of the 
related metadata, as claimed by Applicant. AppHcant further maintains that, as 
correctiy noted by the Examiner, Bums '694 does not refer to an encrypted access 
token; the token having a hash value; the hash value including a version number; 
respectfully neither does Gutum '075. 
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Conclusion 

Applicant amends the independent claims to particularly point out and 
distinctly claim that the file/object can be updated without modification of the related 
metadata, which amendment is neither taught or suggested by Bums '694 nor by 
Guturu '075. AppUcant requests the Examiner to review the amended claims, to enter 
the amendments because they incorporate the limitations of claims that have akeady 
been examined and because the amendments put the claims in condition for 
allowance and/or better condition for appeal. If the Examiner thinks it would expedite 
the prosecution and the issuance of the patent, he is encouraged to telephone the 
Attorney listed below. 



Date: 28 July 2004 



By 



Ojanen Law Offices (OLO) 
2665 Riverside Lane NE 
Rochester, MN 55906-3456 



Respectfully subniit^fed, 




Karuna Ojanen 
Registration No. 32, 
(507) 285-9003 voice 
(507) 252-5345 fax 
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